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Commissioner for Patents 
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AFFIDAVIT OF JAMES MARTUCCI UNDER 37 C.F.R, § 1.131 

Sir: 

I, James Martucci, being duly sworn, hereby state: 

1. I am one of the named inventors of the subject matter claimed in the above- 
identified patent application and am familiar with the inventions disclosed therein. 

2. I conceived of the inventions of claims 1 to 191 in this country at least as early as 
November 30, 2001, as evidenced by a memorandum which I helped draft, a copy of which is 
attached as Exhibit A. 

3. On December 3, 2001, I was copied on correspondence between Tuan Bui, a 
named inventor of the above-identified patent application, and our attorneys regarding the 
preparation and the subject matter of the above-identified patent application. 

4. On or about December 9, 2001, I prepared comments regarding the preparation 
and the subject matter of the above-identified patent application. 

5. On December 11, 2001, 1 forwarded my comments regarding the preparation and 
the subject matter of the above-identified patent application to my attomey for review. 
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6. On December 14, 2001, 1 met with my attorneys to discuss the preparation and the 
subject matter of the above-identified patent application. 

7. I received a draft of the above-identified patent application from my attomeys on 
or about January 3, 2002. 

8. I reviewed the draft patent application and provided my attomeys with my 
comments regarding same on January 14, 2001. 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true and further, I acknowledge 
that willful false statements and the like are punishable by fine or imprisonment, or both, under 
§1001 of Title 18 of the United States Code and may jeopardize the validity of the application or 
any patent issuing thereon. 
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FURTHER AFFIANT SAYETH NOT: 



Date Signed 


State of ) 

)SS. 

County of j^^C ) 

On this day of /^^^Uacyy^ , 2007, before me, a notary public, in 

and for the aforementioned state and coun^, personally appeared the person whose name is 
subscribed to the foregoing instrument, and executed the foregoing instrument in my presence 
for the purpose contained therein, by signing his name hereto. 

IN WITNESS WHEREOF, I hereto set my hand and official seal. 

Date: 

, . Notary Public ^ 
My Commission Expires: <^ //i^/CP 


T 


OFFICIAL SEAL 
KORIRCAYA 

MOTARY PUBLIC - STATE OF ILLINOIS 

Mr COMMISSION iMm&m\m 
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Exhibit A 


To: Fran Kowalik, Esq. 

From: Tuan Bui & Jim Martucci 

Subject: Detailed Description of Method to Program a Medical Device in a Network 
Date: November 30, 2001 


This document will describe alternative methods of progranmiing a medical device within a 
computer network structure. 

Background 

The use of medical devices at the patient point of care (POC) has historically been accomplished 
using manual data management processes, (i.e., programming the device to the appropriate 
settings for a specific use, recording the output data and alarm conditions generated during 
routine use of the device on a patient) - via pen and paper data collection. The advent of wired 
computer networks in the early 1960s and the subsequent implementation of computer network 
standards such as Ethernet in the 1970s resulted in the growing use of computers to automate 
manual processes such as described above. However, medical institutions do not typically utilize 
such networks to the extent of including the point of care , i.e., the use of Ethernet at the patient 
bedside occurs is less than 10% in US hospitals (although the network is very commonly wired 
to the nursing station location). Possible reasons for the lack of connection to POC are: 1) the 
completion of the network to the POC in existing hospital facilities was cumbersome and costly 
2) the presence of the wired network at POC may not have been worthwhile until medical 
instruments that can use those networks became available, 3) There are no standard 
communication protocols to enable instruments to easily communicate (although a great deal of 
effort has been focused on lEE 1073 and HL7, for example) and 4) there may be a multiphcity of 
different devices at the POC and these devices need to roam or move with the patient making the 
use of a wired solution difficult. 

Starting in the 1980's the use of wireless computer networks, both proprietary (such as Proxim) 
and open (such as IEEE 802.11 "wireless Ethernet") enabled hospitals to use medical devices on 
patients and connect their input and output data via a wireless technology. This allowed 
hospitals to workaround issues 1-4 above because the network was relatively easy to install, 
devices were becoming available, the standard was Ethernet and the devices could roam. 

Method for Programming Medical Devices, Including Infusion Pumps 

Normally, the data set for programming a medical device, such as an infusion pump, originates 
with the physician order for a drug, which is captured in the database of the hospital pharmacy 
system. There may be exceptions such as emergency situations, or the use of an alternate site 
infusion center, but in the hospital environment, the pharmacy database is the key source of data. 
Today, the transfer of information from various aspect of the patient care, from order entry 
through the pharmacy to the progranmiing of an infusion pump, is done manually: The process 
of generating a prescription label from the pharmacy system is done manually, and the clinician 


Memo to Fran Kowalik, November 30, 2001 

Baxter Confidential 


Page 1 of 6 


manually programs that prescription data set into an infusion pump and manually captures the 
delivery history from the infusion pump to a medication administration record. 

This invention proposes to program the medical device directly from the pharmacy database 
using a wireless computer network, including handheld devices at the POC to direct the process. 
It is integrated with a bar coding system to automatically verify the correct patient and 
prescription information as outlined below. The following is an outline: 

• Option 1 : Set Infusion Parameters Automatically 

• Scan patient 

• Scan bag 

• Scan pump 

• If the patient bag and pump match, the system automatically uploads infusion parameters from 
pharmacy system (CIS Database in Figure 1 below) to infusion pump. 

• Option 2: Alternative Scheme to Set Infusion Parameters 
Manually 

• Nurse programs the pump manually. 

• Prescription data is transmitted to the network from the pump via the wireless network 

• Prescription data is checked against the order in the database 

• CIS database sends a real-time warning to the PDA if there was a wrong entry 

• System provides real-time tracking of flow rate and operating conditions of infusion pump. 
Alarm conditions are communicated to PDA from CIS database based on assigned patients. 

• Additional Feature of Tracking Clinical Documentation for 
Infusion Flow Rate Changes 

• Nurse scans bag. 

• Nurse enters flow rate changes in the PDA (for mandatory documentation. 

• Information is automatically sent to the CIS database in pharmacy for production scheduling 
updates. 

The following is an outline of the clinical verifications that occur as a result of these steps. 

• Scan pump barcode 

• Identifies pump 

• Scan patient barcode 

• Verify /?fGHT patient 

• Scan bag barcode 

• Verify RIGHTbag 

• Verify in real-time whether order is still active 

• Verify fi/GWT start time 

• Verify RIGHTbag sequence 

• Clinical alerts, pre/post-admin actions 
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Figure I: Typical System Configuration for Invention 
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The following are potential inventive claims to support the invention. These proposed claims 
outline some altematives that may not be described in detail above, but should be self -evident 
based on the background description. 

CIS Server directly programs medical device 

1) A method to control the delivery of medical treatment to a patient from a medical device, 
comprising of: 

• Storing the medical treatment data in the first processor (medical treatment data = patient 
identification data, medication data, medical device operating parameters) 

• Inputting patient identification data from a first source into the second processor. 

• Inputting medication identification data from a second source into the second processor. 
Medication data include patient identification data. 

• Verifying that the patient identification data from the first source matches with the patient 
identification data from the medication data. 
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• Communicating the medication data and the patient identification data from the second 
processor to the first processor. 

• Comparing the conununicated patient identification data with the stored data in the first 
processor (using the first processor?). 

• Communicating the medical device operating parameters to the medical device from the 
first processor and programming the medical device according to the communicated 
operating parameters. 

2) The method of claim 1 further comprising the steps of communicating the medical device 
operating parameters to the second processor. 

CIS server directly programs medical device and user confirms 

3) A method to control the delivery of medical treatment to a patient from a medical device, 
comprising of: 

• Storing the medical treatment data in the first processor (medical treatment data = patient 
identification data, medication data, medical device operating parameters) 

• Inputting patient identification data from a first source into the second processor. 

• Inputting medication identification data from a second source into the second processor. 
Medication data include patient identification data. 

• Verifying that the patient identification data from the first source matches with the patient 
identification data from the medication data 

• Communicating the medication data and the patient identification data from the second 
processor to the first processor 

• Comparing the communicated patient identification data with the stored data in the first 
processor (using the first processor?). 

• Communicating the medical device operating parameters to the second processor. 

• Confirmation of the medical device operating parameters on the second processor. 

• Communicating the confirmation to the first processor. 

• Communicating the confirmed medical treatment data from the first processor to the 
medical device and progranmiing the medical device according to the conmiunicated 
operating parameters 

4) The method of claim 3 further comprising the steps of: 
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Communicating from the medical device to the second processor to acknowledge the completion 
of the progranmiing of the medical device according to the communicated operating parameters 


POC device programs medical device from bar code and CIS server confirms 

5) A method to control the delivery of medical treatment to a patient from a medical device, 
comprising of: 

Storing the medical treatment data in the first processor (medical treatment data = patient 
identification data, medication data, medical device operating parameters) 

Inputting patient identification data from a first source into the second processor. 

Inputting medication identification data and medical device operating parameters from a 
second source (via bar code, or RHD, or magnetic stripe, or OCR) into the second 
processor. Medication data include patient identification data. 

Verifying that the patient identification data from the first source matches with the patient 
identification data from the medication data 

Communicating the medication data, the medical device operating parameters and the 
patient identification data from the second processor to the first processor. 

Comparing the communicated patient identification and medical device operating 
parameters data with the stored data in the first processor to confirm its' continued 
validity for patient care. 

(Optional) Communicating the medical device operating parameters to the second 
processor. 

(Optional) Confirmation of the medical device operating parameters on the second 
processor. 

(Optional) Conmiunicating the confirmation to the first processor. 

Communicating the confirmed medical treatment data from the first processor to the 
medical device and programming the medical device according to the confirmed 
operating parameters 

Medical device is POC device- no second processor 

6) A method to control the delivery of medical treatment to a patient from a medical device, 
comprising of: 

• Storing the medical treatment data in the first processor (medical treatment data = patient 
identification data, medication data, medical device operating parameters) 
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• Inputting patient identification data from a first source directly into the medical device 
(via bar code, or RPID, or magnetic stripe, or OCR), 

• Inputting medication identification data and medical device operating parameters from a 
second source (via bar code, or RFED, or magnetic stripe, or OCR) directly into the 
medical device. Medication data include patient identification data. 

• Verifying that the patient identification data from the first source matches with the patient 
identification data from the medication data 

• Communicating the medication data, the medical device operating parameters and the 
patient identification data from the medical device to the first processor. 

• Comparing the communicated patient identification and medical device operating 
parameters data with the stored data in the first processor to confirm its' continued 
validity for patient care. 

• (Optional) Communicating the medical device operating parameters to the medical 
device. 

• (Optional) Confirmation of the medical device operating parameters on the medical 
device. 

• (Optional) Communicating the confirmation to the first processor. 

• Communicating the confirmed medical treatment data from the first processor to the 
medical device and programming the medical device according to the confirmed 
operating parameters 
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